home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000051_owner-urn-ietf _Wed Nov 6 04:12:52 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  2KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA06632 for urn-ietf-out; Wed, 6 Nov 1996 04:12:52 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA06627 for <urn-ietf@services.bunyip.com>; Wed, 6 Nov 1996 04:12:45 -0500
  3. From: Harald.T.Alvestrand@uninett.no
  4. Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  5.         id AA08918  (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 04:12:43 -0500
  6. Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) 
  7.           id <03736-0@domen.uninett.no>; Wed, 6 Nov 1996 10:10:24 +0100
  8. X-Mailer: exmh version 1.6.7 5/3/96
  9. To: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
  10. Cc: Fisher Mark <FisherM@is3.indy.tce.com>,
  11.         "urn-ietf@bunyip.com" <urn-ietf@bunyip.com>
  12. Subject: Re: [URN] Persistence as part of URN framework
  13. In-Reply-To: Your message of "Tue, 05 Nov 1996 15:54:31 GMT." <2.2.32.19961105155431.006d63e0@sherekhan.jungle.bt.co.uk>
  14. Mime-Version: 1.0
  15. Content-Type: text/plain; charset=us-ascii
  16. Date: Wed, 06 Nov 1996 10:10:11 +0100
  17. Message-Id: <3693.847271411@domen.uninett.no>
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: Harald.T.Alvestrand@uninett.no
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. Bob,
  24. your point is well made that there needs to be some mechanism
  25. which allows an URN buyer to make a guess at how long the resolution
  26. service will stay in place.
  27. This is, I believe, properly part of a business arrangement.
  28.  
  29. For an URN *user*, this may be interesting, but not vital.
  30. It could easily(?) be solved as part of "metadata" on an URN,
  31. together with properties like the changability of the resource
  32. (the URN for "today's weather in Trondheim" has different properties
  33. than the URN for "the weather in Trondheim on Nov 6, 1996 around 10:07"
  34. (cloudy, rainy and about 3 degrees Celsius, BTW)).
  35. But I don't see it as a vital part of the infrastructure.
  36.  
  37. Using DNS TTL records for this is just broken; DNS TTLs are used
  38. to limit caching of name->address mapping, and in the NAPTR proposal,
  39. they should be a fraction of the time one expects to have advance
  40. warning of a server relocation or mapping restructure.
  41. Normal TTLs are on the order of 3 days, and are usually reduced to less
  42. than 1 day before serious network reorganizations.
  43.  
  44.               harald A
  45.  
  46.